Amazon AppStream 2.0 で Active Directoryを利用することに対する私見
しばたです。
昨年末に同僚からの質問を受けてAppStream 2.0でのActive Directoryドメイン利用(ドメイン結合)に関して調査・検証してたのですが、その結果、「こいつは一筋縄ではいかない。取り扱いが非常に難しい。」と思い至ったので本記事で私見を述べようと思います。
公式ドキュメント
AppStream 2.0でのActive Directoryの利用については以下のドキュメントにまとまっています。
ドキュメントによれば、
Amazon AppStream 2.0 フリートと Image Builder を Microsoft Active Directory のドメインに結合することで、既存の Active Directory ドメイン (クラウドベースまたはオンプレミス) を使用して、ドメインに結合されたストリーミングインスタンスを起動することができます。
とあり、その他の部分も含めドキュメント全体的に割とあっさりとした説明がされています。
このドキュメント自体に嘘偽りは無く正しいことが書いているのですが、正直なところ、Acitve DirectoryおよびSAML 2.0による認証にある程度慣れ親しんでいる方でないと適切に読み解けない気がします...
実際私は実環境を作って検証して初めて理解できた点が結構ありました。
AppStream 2.0 ドメイン結合の基本
デフォルトのAppStream 2.0環境では以下の認証方法およびユーザーを使います。
- Windows Serverのフリートインスタンスはワークグループ環境で動作する
- フリートインスタンスOS内部では
PhotonUserという名前のローカルユーザーが使われる - 独自のユーザープールでユーザーを定義し、認証はこのユーザーに対して行う
- SAML 2.0により外部のIdPに対してフェデレーションすることも可能
ここでAppStream 2.0でActive Directoryを利用した場合は、たとえばAmazon WorkSpacesの様に「WorkSpaceインスタンスがドメインに参加してドメインユーザーで直接認証する」ことができれば非常にわかりやすいのですが、実際にはそうではなく
- Windows ServerのフリートインスタンスはActive Direcotryドメイン環境で動作する
- インスタンス起動時に自動でドメイン参加処理が実行される
- フリートインスタンスOS内部にはドメインユーザーでログインすることが可能
- ただし自動ログインではない
- ユーザー認証はSAML 2.0の利用を強制される
- ドメインユーザーで直接認証は不可
となります。
ここで厄介なのは「ユーザー認証はSAML 2.0の利用を強制される」点です。
Active Directory(ADDS)の標準機能だけではSAML 2.0認証はできないので、
- ADFSを追加する
- Azure ADなどの外部IdPとID同期を行う
といった構成が必須となります。
AWSのドキュメントでも下図の様になんらかの「Federation service」[1]を要求しています。
(https://docs.aws.amazon.com/ja_jp/appstream2/latest/developerguide/active-directory-overview.html より引用)
ハイブリッドクラウド環境におけるID設計
この様にAppStream 2.0 ドメイン結合を使おうとするとSAML 2.0認証ができる環境が必要となり、これは事実上「ハイブリッドクラウド環境におけるID基盤が必要」であることを意味します。
ID基盤は組織においてコア中のコアな部分でありAppStream 2.0といったいちアプリケーションの都合で設計するものではありません。
「ID基盤が先、AppStream 2.0は後。」これは絶対に曲げてはいけない原則です。
まずは組織全体のID基盤を設計し、その上でAppStream 2.0ドメイン結合が利用できそうなら使うといった順位づけを意識する必要がありますし、組織のID基盤がAppStream 2.0ドメイン結合の利用に向いていないのであれば採用を諦めるといった判断も必要です。
頑張って「技術的に不可能ではない(でも極めて歪な)構成」を組むこともできるでしょうが、私個人としては決してお勧めしません。
くどい様ですがAppStream 2.0 ドメイン結合を採用する前に極めて重大な前提条件(ID基盤の設計)があることはこの場で強く主張しておきたいです。
補足 : Azure ADを採用した場合のID設計
ハイブリッドクラウド環境におけるID設計の一例として、IdPにAzure ADを採用する場合はDocsの以下のドキュメントが参考になります。
(他にも良いドキュメントはあると思います。)
- ハイブリッド ID 導入戦略の定義
- Azure Active Directory ハイブリッド ID ソリューションの適切な認証方法を選択する
- "シームレス SSO" と "パススルー認証" の一般提供開始 (こちらはOffice 365のドキュメントですが)
基本的にはAzure AD Connect(sync)を使いパスワードハッシュ同期かパススルー認証によるID同期を行う形になるでしょう。
(https://docs.microsoft.com/ja-jp/archive/blogs/office365-tech-japan/aadc-sso-and-passthrough-auth-ga より引用)
この様な組織全体のID設計をまず最初に決めておく必要がある、という事です。
AppStream 2.0 ドメイン結合の構成例
詳細は別途ブログにしようと思いますが、今回私はIdPにAzure ADを採用した場合のAppStream 2.0 ドメイン結合を実際に試していますのでその構成図を実例として紹介します。
Active Directory環境にAWS Managed Microsoft ADを使い、別途用意したEC2にAzure AD Connect(sync)をインストールしパススルー認証を行っています。
利用者はAzure ADのエンタープライズアプリケーションとしてAppStream 2.0を利用する形になります。
なお、ADFSを使う場合の構成も一応試しています。
ただし、2022年現在新規にADFSを構築する理由は一切無いでしょう。
追記 : ブログにしました
IdPにAzure ADを採用した場合のAppStream 2.0 ドメイン結合の構成例をブログにしました。
また、現状AWS Managed Microsoft ADではパスワードハッシュ同期によるID同期ができませんでした。
パスワードハッシュ同期を使いたい場合はEC2でドメインコントローラーを構築すると良いでしょう。
技術上の注意点
設計上の考慮事項の他に技術的な注意点もいくつかあります。
1. Directory Config と DHCPオプションセット
AppStream 2.0 ドメイン結合を利用するにあたり、フリートインスタンス(およびImage Builderインスタンス)をドメインに参加させるための認証情報などを「Directory config」という形で設定する必要があります。
で、このDirectory configですが、下図の様に利用するDNSサーバーに対する設定がありません。
どうやらActive Directoryを利用するにあたりフリートインスタンスのDNS設定はDHCPオプションセットを使う前提の様です。
DHCPオプションセットは適用範囲がVPC全体しかないため、環境によっては設定を変えることができずAppStream 2.0 ドメイン結合の採用を断念せざるを得ない可能性があります。
一応DNSサーバーの設定を変えたカスタムイメージ[2]を作ってAppStream 2.0 ドメイン結合を実現することはできましたが、これが公式にサポートされている手順かは未確認であり、オフィシャルなドキュメントを見つけることもできませんでした。
2. 二段階認証の強制
AppStream 2.0 ドメイン結合を利用した場合、認証は
- AppStream 2.0開始時の認証 (SAML 2.0)
- フリートインスタンス接続時のOS認証 (Kerberos)
の二段階となります。
ID同期(またはフェデレーション)しているとはいえAWSの基盤がユーザーのパスワードを直接保持しているわけではないのでこの様になります。
(フリートインスタンスのOSログイン時に別途パスワード入力を求められる)
AppStream 2.0の利用にあたりこの様なユーザ体験が許容できない場合もあると思うのでご注意ください。
最後に
以上となります。
新年早々若干主張の強い記事を書いてしまった気がしないでもないですが、あくまでも私見ですのでその辺は割り引いてご覧いただけると助かります。
本記事の内容が少しでもAppStream 2.0 ドメイン結合の採用を考えている方の役に立てば幸いです。
